Current methods for detecting duplicate IP addresses do not work well in industrial automation settings. For example, current methods do not resolve problems like: (1) devices powering up without being connected to a network, establishing their IP address (which is potentially a duplicate) and then later connecting (where the duplicate IP address will cause conflicts) (2) a sending device connected to a store and forward device (e.g., switch) having its initial outgoing packets discarded so that the sending device believes it does not have a conflict due to a duplicate IP address, when such a conflict actually exists so that by the time initial outgoing packets are sent, the IP address has been established for the sending device and conflicts due to duplicate IP addresses result and (3) several devices (with potentially duplicate IP addresses) booting up at the same time and attempting to use the same IP address experiencing race conditions that may lead sending devices to believe that they have a unique IP address, when in fact they do not, with resulting conflicts due to duplicate IP addresses occurring.
To understand the problems associated with duplicate IP addresses and the conventional ARP (Address Resolution Protocol) methods (as implemented for broadcast-capable media such as Ethernet) that contribute to such problems, a brief review of Internet addressing (via TCP (Transmission Control Protocol) and IP (Internet Protocol)) is beneficial. ARP is implemented as part of the IP layer and/or is associated with the IP layer in many network protocol stacks and is responsible for resolving IP addresses to physical network addresses. For instance, if a machine “A” recorded the IP address of machine “B” as 111.222.333.444, and if machine A wants to communicate with machine B, then ARP can be employed to determine the physical address of machine B. Machine A will cast a broadcast packet onto the network as an ARP request, with the following question coded into the ARP request:                For the IP address 111.222.333.444, whose physical address I do not know, but with which I would like to communicate, what is the physical address?        
It is to be appreciated that the actual text of the question is not coded in the ARP request, but rather various data values (e.g., bit fields, flags, indicators) are employed to convey the meaning of the question. Because an ARP request is a broadcast request, active machines implementing IP on the network receive the ARP request with the embedded question and query their data stores to determine whether the IP address referenced in the ARP request is their IP address. If an active machine implementing IP on the network determines that it has the referenced IP address, then it replies to the sending machine with the answer:
My IP address is 111.222.333.444, and my physical address is aabbcdeeff. Because sending ARP requests and resolving IP addresses to physical addresses consumes time and computing resources, machines implementing IP and ARP typically have an ARPCache, wherein resolved IP address, physical address pairs are stored. For example, after the exchange detailed above, the ARPCache of machine A may contain, among other records:
IP addressPhysical address111.222.333.444aabbcdeeff address just resolved (machine B)11.22.33.441234abcd Machine A's address
The entry for 11.22.33.44 belongs to machine A itself, and is generally considered a “static” entry that is not changed dynamically.
Problems with duplicate addresses can arise when a second machine connects to the network and broadcasts its IP address and physical address onto the network. For example, if the aforementioned machines A and B are communicating, with machine A having the ARPCache table described above, and during that time, machine C boots up, where machine C has the same IP address as B, a duplicate IP address conflict may ensue. For example, machine C, according to one ARP protocol may broadcast an ARP message that conveys the information that:                I am machine C, my IP address is 111.222.333.444 and my physical address is 579acf579.Machines implementing IP and ARP may then place the newly provided address resolution pair in their ARPCaches, and may overwrite any previous mapping for the IP address (assuming, for example, that the IP/physical address resolution was updated), except that static addresses will not be overwritten. Thus, the ARPCache for machine A could change to:        
IP AddressPhysical Address111.222.333.444579acf579 address just changed (machine C)11.22.33.441234abcd Machine A's address
Henceforth, packets intended to be transmitted from A to B are routed from A to C, which is conventionally undesirable. Existing communication streams (e.g., TCP connections) between Machine A and Machine B may be interrupted. Machine C may then receive incoming packets that were intended for Machine B. In industrial automation applications where control information is being sent over a network, this could comprise the integrity and safety of the system. Thus, conventionally, network administrators have been faced with the difficult task of preventing the use of duplicate IP addresses and, if such prevention is not successful, the difficult task of debugging duplicate IP address problems. Thus, there remains a need for a system and method for mitigating the problems caused by such duplicate addresses.